home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0023.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  12.9 KB  |  296 lines
  1. For those interested, this is the functional requirements document
  2. that CMU has for our next-generation mail system.
  3.  
  4. Some of the features listed herein are inside the domain of IMAP, some
  5. are not.
  6.  
  7. ------------------------------
  8.  
  9.         Andrew II Mail Functional Requirements
  10.                  Sep 15, 1992
  11.  
  12. * Introduction
  13.  
  14. This document describes the functional requirements of the Andrew II
  15. Electronic Mail project.  The purpose of the project is to provide an
  16. electronic mail system for users who use the Andrew system and any
  17. other organizational computing facility on campus that desires to use
  18. it.
  19.  
  20. Our experience with the Andrew Mail System has shown a number of
  21. problems with its design, leading to problems with performance and
  22. difficulty in administration.  This project will attempt to implement
  23. a replacement mail system which corrects many of these problems.
  24.  
  25. The Andrew Mail System has many useful features not found in other
  26. mail systems.  Some of these features are important to the user
  27. community, others are of dubious value.  Determining which features of
  28. the Andrew Mail System are important and reimplementing them in the
  29. new mail system is an important part of this project.
  30.  
  31. * Organization
  32.  
  33. The remainder of this document contains three sections, requirements
  34. for functions to be provided to users, requirements for functions to
  35. be provided to administrators, and design constraints.
  36.  
  37. Each listed feature is given a priority.  Design, resource, and
  38. performance constraints will most likely prohibit implementation of
  39. all features.  The priorities are:
  40.  
  41.     Required    - The Andrew II mail system must have this feature
  42.     Highly desired    - The mail system should have this feature
  43.               unless it would be overly expensive to implement.
  44.     Nice        - The mail system should have this feature
  45.               if it is easy to implement.
  46.     Low priority    - No real effort will be put into providing
  47.               this feature
  48.  
  49.  
  50. * User requirements
  51.  
  52. It is REQUIRED that there exist at least one user client for each of
  53. the X based workstation, Unix terminal, Mac, and PC environments.  For
  54. all of them to have the same or similar user interface is HIGHLY
  55. DESIRED.  Subject to the constraint that they be consistent across
  56. platforms, user clients should conform to the user interface
  57. guidelines of their respective platforms.  (Our users span the various
  58. platforms.  Several of them move from platform to platform.
  59. Consistency across platforms will improve training.)
  60.  
  61. Ability to manage folders is REQUIRED.  (Many users depend on ability
  62. to classify messages).  The ability to optionally store folders on
  63. local media is HIGHLY DESIRED.
  64.  
  65. Some form of subscription/"master update" service is REQUIRED.  The
  66. ability for the service to maintain the read/unread state for each
  67. message in a folder is HIGHLY DESIRED.  (system needs to keep track of
  68. which bboards the user is interested in.  "master update" service
  69. tells which of user's subscribed folders have new messages--is
  70. necessary in order to keep performance acceptable.  While AMS' "quit
  71. here" line is sufficient for recording what messages in a folder a
  72. user has read, keeping read/unread state per message allows users to
  73. read the messages in a bboard in a more presentable order.  For
  74. example, they could read all messages with a given subject before
  75. moving to messages with a different subject.)
  76.  
  77. The ability to search within a folder by subject and/or sender is
  78. REQUIRED.  The ability to do other searches would be NICE.  For
  79. searches by subject, sender, etc to search the entire field (instead
  80. of truncating to a fixed number of characters) is HIGHLY DESIRED.
  81.  
  82. The ability to send and receive files as enclosures is REQUIRED.
  83. Full, generalized multimedia support would be NICE.  If provided,
  84. multimedia support should be done through the MIME standard.
  85.  
  86. Support for local and/or remote printing of messages is REQUIRED.
  87.  
  88. The system is REQUIRED to not drop mail, short of hardware failures.
  89. (Once submitted, mail must either be delivered to the recipient(s) or,
  90. if that is not possible, returned back to the sender.  Losing data for
  91. frivolous reasons (network outage, resource shortages, server
  92. unavailability) is unacceptable.)
  93.  
  94. Authenticated delivery of local mail is REQUIRED.  This is a feature
  95. of AMDS that is expected by users.  Not only does it protect against
  96. users being mislead by forged mail, it allows mail-based services like
  97. EzFax and restricted-posting bboards to work.  (If mail system cannot
  98. be assured that mail claiming to be sent from a local user was in fact
  99. sent from that account, it must indicate it as such.  The delivery
  100. system is allowed to lose this assurance under adverse conditions.)
  101.  
  102. A directory service of users which supports "fuzzy matching" name
  103. lookups is REQUIRED.  Users are used to the features of the White
  104. Pages facility of AMDS and some equivalent is necessary.
  105.  
  106. Some User-settable forwarding address facility is REQUIRED.  The
  107. ability for changes to take effect immediately is HIGHLY DESIRED.
  108.  
  109. In order to support beta-testing and a smooth transition from
  110. AMS/AMDS, a per-user "Leap of Faith" style phase-in mechanism is REQUIRED.
  111. (Users must be able to specify that they wish to use the new mail
  112. system instead of AMS.  This transition need not be reversible.  At
  113. some point, this transition may be forced upon users.)
  114.  
  115. The "integrated Mail and Bboards" concept is HIGHLY DESIRED.
  116.  
  117. A method for notification of new mail for a user is HIGHLY DESIRED.
  118. Zephyr is the most likely notification mechanism.  (Users like to know
  119. when new mail arrives.)
  120.  
  121. The ability to keep copies of all outgoing messages is HIGHLY
  122. DESIRED.
  123.  
  124. The ability to perform well for mail-only users is HIGHLY DESIRED.
  125. If user doesn't read bboards, they shouldn't take any performance hit
  126. imposed by the bboard system.  (There is a large number of users who
  127. only use mail)
  128.  
  129. The ability to do archival and/or compression of old messages is
  130. HIGHLY DESIRED.
  131.  
  132. A uniform bboard addressing scheme (for example, being able to post to
  133. any bboard by addressing mail to "bb+nameofbboard") is HIGHLY DESIRED.
  134. The .MS.DirectPost facility of AMS has proven to be confusing to users.
  135.  
  136. Per-user mail aliases (address books) are HIGHLY DESIRED.  The user's
  137. address book should be available regardless of the location or
  138. platform being used.
  139.  
  140. Support for user-created/maintained distribution lists is HIGHLY
  141. DESIRED.  The ability to have restricted-sending distribution lists
  142. would be NICE.
  143.  
  144. Support for a user-defined portion of the address namespace
  145. (userid+whatever) is HIGHLY DESIRED.  (This is an invaluable aid to
  146. users who do automated filing of incoming mail.)
  147.  
  148. Some form of automatic filing mechanism for user's mail is HIGHLY DESIRED.
  149.  
  150. Duplicate delivery elimination (by examining the message-id header) is
  151. HIGHLY DESIRED.  Sometimes a message from an external system is
  152. delivered twice.  AMDS currently avoids delivering the excess copies.
  153.  
  154. The ability to eliminate the multiple presentation of messages that
  155. have been crossposted (by tracking the message-id field) would be
  156. NICE.  (When a message is crossposted, it should only be presented to
  157. the user once.)
  158.  
  159. Support for threading would be NICE.  (Threaded readers group messages
  160. that are replies to the same post together, allowing users to read
  161. all messages in the same conversation together)
  162.  
  163. Support for "kill files" would be NICE.  (Kill files allow users to
  164. specify that they want to ignore messages on a bboard with, for
  165. example, a given subject or from a specific poster.  They are an aid
  166. to reading large volume bboards.)
  167.  
  168. Support for subscription invitations would be NICE.  (These are
  169. messages that cause the client to be prompted to subscribe to a given
  170. folder.)
  171.  
  172. An equivalent to the standard Unix "vacation" facility would be NICE.
  173. (User can configure their account to inform users that send them mail
  174. that they are unavailable for a certain time.)
  175.  
  176. Support for direct delivery to folders would be NICE.  (One mechanism
  177. for supporting private bboards)
  178.  
  179. Support for requesting a return receipt would be NICE.  (A return
  180. receipt is an automatically generated message that notifies the sender
  181. of a piece of mail that the mail was successfully delivered to the
  182. recipient.)
  183.  
  184. Explicit support for delivery of mail to a user's workstation is
  185. LOW PRIORITY.  There are problems administrating a system which relies
  186. on components that the computing facility has no administrative
  187. control over.  It is extremely difficult to make such a system
  188. reliable.
  189.  
  190. Equivalents to AMDS' dir-insert, fs-members, and file-append features
  191. are LOW PRIORITY.  (These features are infrequently used.)
  192.  
  193. Direct support of X.400 is LOW PRIORITY.  The address syntax is
  194. unwieldy and there are several technical show-stoppers, such as the
  195. fact that an X.400 Message Transport Agent is allowed to silently
  196. discard messages due to "congestion".
  197.  
  198. The ability to support "votes" is LOW PRIORITY.  (This is a feature of
  199. dubious value.)
  200.  
  201.  
  202. * Administrative requirements
  203.  
  204. Enforcement of disk space quotas is REQUIRED.  (Administrators need to
  205. have control over resources and be able to avoid abuse of the mail
  206. system as additional storage.)
  207.  
  208. Support for global mail aliases and mailing lists is REQUIRED.
  209. (Mail aliases and published mailing lists are frequently used.)
  210.  
  211. The ability to efficiently handle large, frequently read bboards is
  212. REQUIRED.  (We have several such bboards.)
  213.  
  214. The ability to have bboards with restricted reading is REQUIRED.
  215. (Organizations use bboards for internal discussions which they do not
  216. want to be available to outside users.)
  217.  
  218. Some form of BBoard filing mechanism is REQUIRED.  (This is necessary
  219. in order to have bboards.)
  220.  
  221. The ability for the bboard filing mechanism to enforce restricted
  222. posting to bboards is REQUIRED.  The ability for it to be general
  223. enough to handle special setups, such as advisor, is HIGHLY DESIRED.
  224. (Enforcement of restricted-posting bboards is necessary in order to
  225. support "official" and other moderated-style forums.  If the filing
  226. mechanism isn't general enough to handle such setups as advisor,
  227. special-purpose programs to handle this can be written.)
  228.  
  229. A mechanism to handle administration of bboards (manipulate ACLs,
  230. create, delete, etc.) is REQUIRED.  The ability for parts of this
  231. administration to be distributed to outside groups is HIGHLY DESIRED.
  232. (The bboard system needs to be maintained in some manner.  If this
  233. maintenance can be distributed, this reduces the load on the central
  234. maintainers and allows outside groups to be given greater flexibility
  235. within their own part of the bboard system.)
  236.  
  237. The ability to distribute the bboards across servers is REQUIRED.
  238. (The client must therefore have some mechanism for finding the
  239. server(s) for a given bboard.  Distribution of bboards is necessary in
  240. order to handle a large load.)
  241.  
  242. The ability to distribute users across servers is REQUIRED.  (This is
  243. necessary in order to handle large numbers of users)
  244.  
  245. The ability to move users and bboard trees between servers (in order
  246. to load-balance) is REQUIRED.
  247.  
  248. The ability to purge bboards at administratively defined rates is
  249. REQUIRED.  (Old messages have to be removed at some point.  The rates
  250. at which bboards are purged need to be adjustable in order to allow
  251. for variations in resource usage and importance.)
  252.  
  253. Monitoring of centrally maintained resources is REQUIRED.  Usage and
  254. resource monitoring of other parts of the mail system is HIGHLY
  255. DESIRED.  (Administrators need to do resource planning, budget
  256. justification, detection and diagnosis of problems.)
  257.  
  258. The ability to "Short Circuit" local delivery of mail, to both
  259. andrew.cmu.edu and to CMU.EDU is HIGHLY DESIRED.  This is expected to
  260. increase the performance and reliability of the delivery system
  261. significantly.  (For example, both Andrew and CS know how to query the
  262. CMU.EDU database directly, so they can deliver mail directly to the
  263. user's forwarding address instead of making the mail be processed by
  264. the central CMU.EDU servers)
  265.  
  266. The ability to replicate bboards on multiple servers is HIGHLY DESIRED.
  267. (This would be an aid to distributing load.)
  268.  
  269. Administratively settable per-address bounce messages would be NICE.
  270. (This is the ability for an administrator to specify that mail sent to
  271. a given address is to be returned with an administratively settable
  272. error message.  This is a feature of AMDS that is useful for dealing
  273. with suspended accounts.)
  274.  
  275.  
  276. * Design constraints
  277.  
  278. The mail system is REQUIRED to use a client/server architecture.
  279. (This architecture is necessary to support "mobile" users, those who
  280. access their mail from different places.)
  281.  
  282. Avoiding any reliance on a shared filesystem service is REQUIRED.
  283. Experience with AMDS shows that layering on top of a shared filesystem
  284. leads to serious problems with performance and availability.  We may
  285. allow users to configure their own environment to make part of their
  286. mail service rely on a shared file system.
  287.  
  288. Whenever a component of the mail system needs authentication, it is
  289. REQUIRED to support Kerberos V4.  (Kerberos V4 is the authentication
  290. mechanism currently used by Andrew.)
  291.  
  292. The use of standardized protocols is HIGHLY DESIRED.  If we need to
  293. design a new protocol, we should work to make it standardized.
  294.  
  295.  
  296.